FI-AE 15 DevOps — CI-CD-Pipelines und Container

Worked Example: Automatisierte Bereitstellung einer Node.js-Anwendung via Docker und Kubernetes

SITUATION: Als Junior-DevOps-Ingenieur bei der „TechStart GmbH“ erhalten Sie die Aufgabe, die manuelle Bereitstellung der Webanwendung „ShopFront“ zu automatisieren. Bisher wurde der Code manuell auf den Server kopiert, was zu Inkonsistenzen zwischen Entwicklungs- und Produktivumgebung führte. Ziel ist es, ein reproduzierbares Docker-Image zu erstellen und dieses über ein Kubernetes-Deployment in der Testumgebung bereitzustellen.

DURCHFÜHRUNG: Wir gehen davon aus, dass der Node.js-Code bereits in einem Git-Repository liegt. Der folgende Walkthrough demonstriert die lokale Erstellung des Images und die anschließende Konfiguration in Kubernetes.

Zunächst erstellen wir das Dockerfile, das die Bauanleitung für das Image definiert. Wir nutzen ein schlankes Basis-Image, um die Sicherheitsfläche zu minimieren.

# Dockerfile
FROM node:18-alpine

# Arbeitsverzeichnis im Container setzen
WORKDIR /app

# Abhängigkeiten kopieren und installieren
COPY package*.json ./
RUN npm ci --only=production

# Quellcode kopieren
COPY . .

# Exponierten Port definieren
EXPOSE 3000

# Startbefehl für die Anwendung
CMD [ "node", "server.js" ]

Nachdem das Dockerfile erstellt ist, bauen wir das Image lokal. Der Befehl -t taggt das Image mit einem Namen und einer Version, was für die spätere Identifikation in der Registry entscheidend ist.

docker build -t shopfront:v1.0 .

Um sicherzustellen, dass das Image korrekt funktioniert, starten wir es lokal in einer isolierten Umgebung. Dies simuliert die spätere Ausführung im Cluster.

docker run -d --name shopfront-test -p 3000:3000 shopfront:v1.0

Im nächsten Schritt erstellen wir das Kubernetes-Manifest deployment.yaml. Dieses deklariert den gewünschten Zustand des Clusters. Wir definieren hier drei Repliken, um Verfügbarkeit zu gewährleisten, und verweisen auf das zuvor erstellte Image.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: shopfront-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: shopfront
  template:
    metadata:
      labels:
        app: shopfront
    spec:
      containers:
      - name: shopfront
        image: shopfront:v1.0
        ports:
        - containerPort: 3000
        resources:
          requests:
            memory: "128Mi"
            cpu: "250m"
          limits:
            memory: "256Mi"
            cpu: "500m"

Wir wenden dieses Manifest auf den Kubernetes-Cluster an. Der apply-Befehl sorgt dafür, dass der Cluster den aktuellen Zustand mit dem gewünschten Zustand abgleicht und ggf. Änderungen durchführt.

kubectl apply -f deployment.yaml

Schließlich erstellen wir einen Service, um den Traffic von außen auf die Pods zu leiten. Ohne diesen Schritt wäre die Anwendung im Cluster isoliert und nicht von außen erreichbar.

kubectl expose deployment shopfront-deployment --type=LoadBalancer --port=80 --target-port=3000

ERGEBNIS: Nach Ausführung der Schritte ist die Anwendung „ShopFront“ hochverfügbar im Cluster verteilt. Die Ausgabe von kubectl get pods zeigt drei laufende Pods im Status Running. Der LoadBalancer-Service hat eine externe IP-Adresse erhalten, über die die Anwendung im Browser erreichbar ist. Bei einem Ausfall eines Pods übernimmt Kubernetes automatisch die Neustartlogik, um die gewünschte Replika-Anzahl von drei wiederherzustellen.

REFLEXION: Sie haben verstanden, wie Containerisierung die Portabilität gewährleistet: Das gleiche Image, das lokal getestet wurde, läuft identisch im Cluster. Eine typische Falle war das Vergessen der resources-Limits im Deployment; ohne diese könnte ein einzelner Pod den gesamten Node im Cluster mit Speicher überlasten und andere Anwendungen abstürzen lassen. Durch die Definition von Requests und Limits wird die Stabilität des gesamten Clusters gesichert.